A Framework for Method Integration

In the information systems field, there is growing interest in the issue of method integration. The aim of this paper is to begin to build a framework for the understanding and evaluation of work in this area, using a new model of a method to analyse the 'method for method integration' and its resulting products. Introduction In the software engineering and information systems development communities there is considerable interest in the issue of 'method integration', that is, discovering ways in which methods can be combined in order to improve the development process and outcome. In this paper we examine current approaches to method integration, and begin to build a framework to support the analysis and evaluation of method integration. Firstly, we justify the need for a method integration framework by reviewing some of the areas in which method integration is being attempted, and the questions that arise as a result. We define a model for a method, which is then used to define our meta-method for method integration. This meta-method is examined at a high level, identifying five different types of method integration; and by using the model of a method to examine in greater detail the output, or integrated method, for each type of method integration. Finally, we summarise the main points and propose areas of further work. A recent, detailed analysis of method integration is given by Kronlöf (1993). This work is an outcome of activities carried out in the Esprit Project 2565 ATMOSPHERE, and the book's objective was to contribute to the development of 'method engineering': 'We envisage that in the future the development and customisation of methods will be supported by well-defined meta-methods based on a firm conceptual framework.' Kronlöf (1993) In this paper, we shall show where we have built on the work of Kronlöf, and where we propose additional concepts of relevance to the study of method integration. We have also been influenced by Brown and McDermid (1992) who explore integration in a (computer-based) software development environment. The need for a method integration framework Method integration work has been identified in the following areas: 1. Combining formal and structured methods (eg Polack, Whiston and Mander (1993), Semmens and Allen (1991), Fencott and Lockyer (1993), Larsen, Plat et al (1991)). Formal notation methods such as Z have not been widely adopted, one reason being their intimidating appearance to many developers and users. Method integration work in this area seeks to use the formal notation methods to provide a rigorous foundation for the structured methods (such as Yourdon Systems Method or SSADM), and to improve the usability of the formal notation methods by adding the diagrammatic notations of structured methods. 2. Combining 'hard' and 'soft' methods, for example Multiview (Avison and Wood-Harper (1990)) and COMPACT (CCTA (1989)), which both use a combination of methods drawn from the hard structured methods and from the softer ETHICS (Mumford (1983)) and Soft Systems Methodology (SSM) (Checkland (1981)). Other examples can be found in recent work attempting to combine SSM with data flow diagrams (eg Merali (1992)) or with data-focused approaches (eg Lewis (1993)). 3. As new versions of methods are released, they tend to increase their repertoire and include other methods within them. For example, the latest version of the Yourdon Systems Method (Yourdon (1993)) includes a type of entity life history analysis, which was not previously part of the method (Yourdon (1989)). 4. There is a recognition that a contingent approach to methods is often necessary (Olle (1991)), choosing and combining methods to suit the particular situation, since there is not one all-purpose method. In Kronlöf's concept of method engineering, a set of methods appropriate to the project is chosen, they are modified as necessary, novel methods are developed to 'bridge the gaps' between the chosen methods, and the modified and developed methods are combined to form a new and more comprehensive method (Kronlöf (1993)). Some methods are deliberately designed as 'toolbox methodologies', allowing the user to choose the appropriate methods from a given selection and combine them into a specific method for the project in question eg Multiview (Avison and Wood-Harper (1990)). Other methods, whilst having a well-defined process model, include a tailoring step eg SSADM (Eva (1992)), where the user adapts the method to suit the project, perhaps deciding on an appropriate subset of models and steps. In all of the above cases, there are the concepts of choosing appropriate methods for a specific project, and then combining them together in a meaningful way. 5. Reuse of analysis and design products is as important as the reuse of program code (Poulin, Caruso, Hancock (1993)). It is inevitable that systems will have been developed in the past using methods which are no longer used by an organization. A way needs to be found to link the products of the older methods into the organization's current methods. 6. In the construction of Integrated Project Support Environments (IPSEs) and other computer-based software engineering tools, there is interest in tool integration. Kronlöf (1993) points out that tool integration tends to focus on the implementation of the integration rather than on the intention (or motivation) of the integration. They suggest that tool suppliers tend to overlook the methodological issues of the engineering process to be supported, and they contend that method integration is a prerequisite for successful tool integration. Brown and McDermid (1992) classify method level integration as the highest level in their classification scheme for tool integration, and point to some current research projects which are examining the way in which this level of integration can be provided in an IPSE. 7. There is increasing interest in integrating software engineering or information systems development methods with methods from other disciplines. For example, Brown and McDermid (1992) point to the need to derive information to support management processes from the technical information produced by software engineers. This implies an integration of management methods with software engineering methods. And Fencott and Hebbron (1994) explore how to combine the traditional methods of safety engineers with those of software engineers. The above list may not be exhaustive, but it serves to indicate the range of current method integration work. In order to critically evaluate the method integration work being carried out, we asked the following types of questions: How do we decide which methods to combine? How can we describe the process of method integration? Do we need a meta-method: a method for method integration? How do we evaluate the results of method integration? For example, does the SSADM and Z integration work in SAZ (Polack, Whiston and Mander (1993)) improve upon the Yourdon and Z integration work of Semmens and Allen (1991)? What criteria do we use to answer that question? Where a new method or new version has been developed, is the new method well-integrated? What do we mean by 'well-integrated'? Are some methods more suited to tailoring than others? Why? Do the types of method integration required depend upon the circumstances or context of a project? Is there a contingent approach to method integration? We concluded that a framework was needed to help in the understanding of method integration : (i) reactively where method integration work has been undertaken, to allow analysis and critical evaluation of the method integration work, and (ii) proactively -to support the tailoring and combination of methods as required. Such a framework will assist our understanding by identifying the different types of method integration, the significant features of each type, and criteria for 'good' design of each type. This will then allow us to analyse and evaluate actual instances of method integration work. Definition of method Before we can address the issue of method integration, we need to define our concept of a method. Kronlöf (1993) defines a method as having four parts: 1. An underlying model which provides a conceptual representation of the product of a method. It is the class of objects represented, manipulated and analysed by the method. Most system engineering methods in fact incorporate more basic methods (each with their own model) in a 'uses' or 'inherits' hierarchy. As a method increases in repertoire and scope it will have a collection of inherited underlying models. Kronlöf still speaks of a method's single underlying model, even though that 'model' may actually be a set of models. 2. A language, which is the concrete means of describing the product of the method, the user interface to the underlying model of the method. It is used to describe the objects represented, manipulated and analysed by the method, and is the concrete counterpart of the underlying model. As with the model, Kronlöf still speaks of the method's single language, even though that language may in fact be a set of languages. 3. Defined steps and ordering of those steps, the process model of the method. 4. Guidance for applying the method, which typically takes the form of informal text in manuals, handbooks, guides etc. A method can itself be made up of other methods, each of which has the same four constituent parts. In the information systems development world (as opposed to software engineering) 'methodology' tends to be used. Olle et al (1991) define a methodology as: 'A methodical approach to information systems planning, analysis, design, construction and evolution.' They also say, 'The concept of modelling is inherent in any information systems methodology.' Jayaratna (1993) defines a methodology as: 'An explicit way of structuring one's own thinking and actions. Methodologies contain models and reflect particular perspectives for thinking about 'reality' based on their embedded philosophical paradigms. A methodology must show 'what' steps to take, 'how' those steps are to be performed and most importantly 'why' [the rationale] the methodology user must follow those steps and in the suggested sequence.' This definition reflects the fact that not all information systems methodologies are in the scientific or engineering paradigm, and hence their underlying philosophy is of significance. In this paper we have chosen to use 'method' in place of 'methodology'(if only for the pragmatic reason that 'methodology integration would be too much of a mouthful). We have used Kronlöf's concept of a method, adding 'philosophy' as a fifth constituent part of a method. We also note that Kronlöf describes the physical nature of 'guidance', whereas we feel the logical content is of greater importance. Indeed it is through examining the guidance content that one can often discover the unstated, underlying philosophy of the method designers and their method. We also feel that the input or initiation trigger of a method, and the final output are of significance. For example, the input to SSM is a 'vague feeling of unease' (Checkland (1981)), in contrast to other methods which take as input a defined problem or a requirements specification. The output of SSM is intended to be consensus about feasible and desirable change: structural, procedural or attitudinal. Consensus about procedural change could be the input to a more engineering-oriented methodology (Miles (1988)). The inputs and outputs of a method are shaped by the underlying philosophy. Our concept of a method therefore has seven constituent parts: input, output, model (set), language (set), steps, guidance and underlying philosophy. We have found it convenient to model a method using two levels. At a strategic level, when first considering the use of a method, we see its input, output and underlying philosophy, and the rest of the method can be thought of as a black box (see Figure 1). Figure 1 When we actually use a method or are otherwise concerned with its detail, we look inside the black box to see the model, language, steps and guidance (see Figure 2). We shall use this concept of a method to structure our outline 'method of method integration' and method integration framework. Framework for method integration philosophy and input The highest level view of our framework uses the model of a method (already defined) to analyse a method for method integration (a meta-method). Firstly, we shall examine the view shown in Figure 1, namely the philosophy, inputs and outputs. The underlying philosophy of our meta-method is based on the following assumptions: (i) methods can and must be tailored and/or combined, (ii) methods can be improved or extended by the incorporation of other methods. (iii) a theory of method integration is needed as a foundation for tool integration. (iv) to carry out any of the above successfully, we must be able to a) analyse what is done and b) critically evaluate what is done. (v) the study of method integration also increases our knowledge of individual methods. Figure 2 In order to increase our understanding of method integration, we have identified five broad categories of method integration, classified on the basis of their inputs or initiation triggers: method-oriented, project-oriented, tailoring-oriented, reuse-oriented and tooloriented. These categories (summarised in Table 1) need not necessarily be discrete ie more than one category may be applied to a particular integration. Table 1 Categories of Method Integration Integration Category Input / Initiation Trigger Problem-solver Output